Getting separate executing entities (processes) to interact with each other is a desirable trait of complex distributed systems. It allows separately executing entities to take advantage of each other's functionality without specifically including that functionality within the entity.
There are several technologies that currently exist that provide this kind of cross-process communication. Microsoft has COM (Component Object Model) and DCOM (Distributed Component Object Model), UNIX systems have CORBA (Common Object Request Broker Architecture). These systems indeed provide this cross binary/process/executable resource access, however, they are complex in that there are numerous details that need to be addressed by a developer using these technologies. This makes use of these features difficult and when installed on systems, require a lot of maintenance, and are fragile (they don't always work correctly) as they require numerous files and configuration settings to exist and be correct. A corrupt hard disk or the accidental erasure of only one of these files can bring a system to a halt.
Newer computer languages have simplified this process. However these newer languages most often found on a narrow range of operating system platforms (Microsoft Windows, for example) and are not available on real-time and safety critical systems. Furthermore, these languages provide difficulty for developers of safety critical systems as they will sometimes perform operations and exhibit behavior that is incompatible with the validation requirements for such systems. For example, some languages perform automatic (and sometimes unpredictable and unbounded) operations that have not been specifically requested by the programmer. While these are considered useful in insuring reliability of general purpose applications, they may be detrimental to specialized systems. Garbage collection is one example, this is where a programs execution is interrupted while memory that is deemed unused is returned to the pool of usable memory. This operation is considered useful for general purpose systems, but because of its unpredictability in terms of when it is run and how long it takes, is problematic in real-time systems. These newer computer languages still require complex installations and numerous files and configuration settings that make the system vulnerable to unexplained failure.
Successfully implementing a system based on COM/DCOM or CORBA requires static and rigid interfaces to exported functionality. If access to an exposed interface is attempted without the correct understanding of its structure, errors will occur in which the functionality behind the exposed interface usually will halt operation completely, and sometimes catastrophically. These interface definitions exist separately from the executable. If these interface definitions become corrupted or if they do not match the executable, then the system will fail in unexpected ways.
COM/DCOM and CORBA have to use an additional compilation step to correctly expose interfaces contained within, for example, a C/C++ program. Building C/C++ programs requires two steps known as the pre-processor step (preparing the code for the compiler) and the compiler step (conversion of C/C++ code into machine language). Both of these operations are performed by the compiler executable itself. If COM/DCOM or CORBA need to be used, a separate file containing the desired exposed interface called an interface definition language (IDL) must be prepared and run through a separate compiler that understands this IDL. The IDL compiler step results in a file that is separate from the binary containing descriptive information about the interface as well as other artifacts. These are not included with the binary and therefore are vulnerable to becoming out of sync with the binary.